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As software developmsat projects have become more and 
more complex, crganiza rio n: 
tures to accomplish them in 
timely manner. This aspect < 
process involves manipulati 
srructnre in such a way as 
the organization 's scarce resources, 
tifies four major determinants 
the organization's strategy for achieving its goals; the 
skills and needs of the people employed; the technology 
employed; and the size of the organization and its subunits. 
Management, by making decisions concerning these determi- 
nants, seeks to develop the structure which will be most 
successful in accomplishing the goals cf *'he organization. 
These managerial decisions are of extreme importance because 
"the choices which too management make are the critical 
determinants of organizational structure and process." 
[Ref. 2: p.548] Because of the impact cf these decisions, i‘ 
is very important that managers of a software development 
project understand what the elements of organizational 
structure are and how they can be manipulated to improve the 
performance of the development process. 

Three elements cf organizational structure noted by 
Stoner [Ref. 1 ] will be the focus of this paper. The first 
element will be the specialization cf activities. This 
concerns the breaking down of the overall project into 
component activities and assigning personnel with special- 
ized training to accomplish those activities for which their 
training makes them most suited, and in which they will be 



most productive. 



The objective 



of the chapter 



on 
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specialization of activities will be the making the critical 
decisicns oi the optimal combination of specialized labor to 
employ, and the optimal quantity of individual specialized 
labor to apply to the software development process- 

The second element will be the size of the work group. 
An analysis of the impact of work group size on productivity 
will be made. The factors which influence work group 
productivity will be explored, and approaches to mitigating 
the negative factors while enhancing the positive factors 
will be examined. The size and composition oi a work croup 
with high productivity potential will be investigated, and 
the manaaerial and systems design techniques needed to 
support this work group will also be noted. 

The third and final element will be the standardization 
of activities. The benefits of activity standardization 
within a software development projec' 



will 



^ ^ T. 



be 



discussed in general terms, 
phase of the process will then 
identify soecific contributions and 
management process. 



The standardization of 
be ar.alvzed in detail 



one 



r9L3V3.r.C9 
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II. SPECIALIZATION OF ACTIVITIES 



A. REASONS FOR SPECIALIZATION 

One of the most important elements of organizational 
sxructure is the specialization of activities. This 
specializanion in the organizational sense includes the 
breaking down cf the project into smaller, specialized 
tasks. The benefits of division of work have been repeat- 
edly demonstrated throughout the history of civilize" ion. 
The order of magnitude improvements in productivity 
resulting from division of work have had profound impact on 
the world’s industrial development. Division of work is 
important because 

no one person is physically able to perform ail of the 
operations in lost complex tasks, nor can anv one person 
acquire all the skills needed to perform the various 
tasks that make up a complex operation. Thus, in order 
to carry out tasks requirina a number of steps, it is 
necessary to parcel out the' various parts or the task 
amcna a number 'of people. Such specialized division cf 
work'allows people to" learn skills and become expert at 
their individual job functions. Simplified tasks' can be 
learned in a relatively short period cf time and be 
completed quickly. [Ref. 1: p. 254] 

In a complex task such as a software development project 
it would be impractical to assign one person to accomplish 
the task by himself. In order to achieve a high quality 
product, this person would not only have to be expert in all 
areas of software development, he would also have to be able 
to provide his own clerical services, administative 
services, computer services, etc. This one-man approach is 
impractical for a multitude of reasons, no'^ the least of 
which is the development time that would be required. With 
development times for projects running into the hundreds or 
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thousands of man-years, only the smillsst of projects would 
be possible. Therefore, division of work in a complex 
development project is absolutely essential to the success 
of the project. 



B. 



SPECIALIZATION IN SOFTS ARE PROJECTS 



The software development project is often broken down 
into a sequence or tasks, phases, or activities such as 
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overall 
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As the rask itself is divided into a variety of 
subrasks, so to must the overall work requirement be divided 
among many individuals. As discussed above, this division 
of labor is necessary to produce a quality product wirhin 
time and cost constraints. The division of labor allows 
individuals to specialize and beoom- expert at certain 
skills. Sysrems analyses, programmers, technical analyses, 
and danabase adm inistranors are some of the specializaniens 
within software develcprasnt projeens. The chief programmer 
team concept as described by Brooks [Ref. 3: p. 32-35], 

makes clear distinctions between the skills, duties, and 
responsibilities of its team members. The specialization 
within the chief programmer ream includes a chief 

programmer, assistanr programmer, administrator, editor, 
secretaries, clerk, toolsmith, tester, and language lawyer. 
This type of team, the individuals within it and their 
duties will be discussed later in the oaoer. 



C. MANAGEMENT DECISIONS 

The thrust of this chapter will be towards developing 
generic conceptual frameworks for the management decisions 
concerning the combination and quantity of the specialized 
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labor skills to employ. The following management decision 
questions will be addressed : 



1) Whar is the optimal mix of the different types of labor 
to employ in the software development process? 

2) What is the optimal quantity of a particular type of 
labor to employ? 



1 . 



pro cess 
systems 
etc . ) 
pro cess 



Iks 2^5=1=22 

a. The Production Process 

The software development process is 
which transforms a particular se-*- of 
analyst labor, programmer labor, compu 
into a desired output. Figure 2.1 



a production 
inputs 
er services, 
models this 




Figure 2.1 Software Development Hodel. 
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The relationship between the inputs into the 
process and the maximum output based upon those inputs 
represents the production function for the process. In 
other words, given the terhnology applied, the output of the 
process is a function of the inputs employed in the process. 
Brooks £Eef. 3] and Fried [Ref. 4] have demonstrated that if 
the other inputs are held constant while one type of labor 
is allowed to increase, that input will, at some point, show 
decreasing marginal prcductivity and will eventually display 
a negative marginal productivity. Figure 2.2 illustrates 
these findings with respect ■^.o programmer labor. The slope 
of the curve in Figure 2.2 represents the marginal product 
of programmer labor with respect to total lin-s of code 
pro dace d. 



^ 




j 



Figure 2.2 Programmer Labor Productivity. 
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If w€ allow two of tha inputs to vary, we can 
develop an isoquant representing all of the possible effi- 
cient combinations of these two inputs which will produce 
the same quantity of output. For the purpose of this argu- 
ment the two inputs used will be systems analyst labor and 
programmer labor. Figure 2.3 illustrates an isoquant which 
represents -^he possible combinations of programmer labor and 
systems analyst labor capable of producing a given quantity 
of software (Qs) . 




Figure 2, 3 A Software Development Isoquant. 

Points A and 3 on the isoquant represent two 
different combinations of programmer and systems analyst 
labor capable of producing the same amount of software; as 
such, they represent two different technological processes 
(within the given technology) used in the production of the 
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software. The slope of the curve, therefore, represents the 
marginal rate of technological substitution (MRTS) of 
programmer labor for systems analyst labor. It can also be 
shown that the marginal rate of technical substitution is 
equal to the ratio of the marginal products of the inputs 
[Esf- 5: p. 158], In symbols: 



MR IS = -MPp/M?sa 



(eqn 2.1) 



w ne r e : 



HPp = marginal product of programmer labor 
MPsa = marginal product of systems analyst labo; 
MRTS = marginal rate of technical substitution. 



b. The Costs 

If we assume that 
amount of funds to expend on 
process, and that the total 
constant and is less than 



COS' 



'.€ organization has a limited 

- V ca Q c* **o 

: cf the fixed inputs reinains 
:otal amount available, then 



there exists an amount which is available to partition among 
the variable inputs: programmer and systems analyst labor. 
In symbols: 



M = Pp*Qp -► ?sa*Qsa 



(eqn 2.2) 



where : 
a 

pp 

Psa 

QP 

Qsa 



the total amount available for programmer and 
systems analyst labor 

the price of a unit of programmer labor 
the price of a unit of systems analyst labor 
the quantity of programmer labor used 
the quantity of systems analyst labor used. 
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If we graph eguation 2.2 we car. represent the 
various possible combinations of programmer and systems 
analyst labor that can be aguired for rhe amount .'I by a 
straight line as in Figure 2.4 . This line is called the 

isocost curve for these input combinations. The slope of 
the isocost curve is negative and can be shown to be equal 
to ?p/Psa. 




Figure 2.4 Isocost Curve. 

If a family of the previously developed isoquant 
curves is superimposed upon the isocost curve of Figure 2.4, 
as in Figure 2. 5, it is possible to graphically determine 
the optimum mix of programmer and systems analyst labor to 
employ in the software development, process. 
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Figure 2.5 The Optinium Labor Six. 

Q1, Q2, ar.Q Q3 represenr isoquants in increasing 

order of quantity of software produced. There may be any 
number of isoquanrs represented on tae graph, but it can be 
seen that output will be maximized for a given cost (M) an 
the point where the isocost curve is tangent to the highest 
isoquant curve. In Figure 2.5 this is poinr B, and Q2 is 
the maximum quantity of software that can be produced for 
the given dollar amount available for programmer and systems 
analyst labor. Alternately, ir could be seated that M is 
the minimum amount that would have to be spenr on programmer 
and systems analyst labor, other factors held constant, in 
order to produce a desired quantity Q2. points A and C 
represent suboptimum utilizarion of resources because the 
same dollar amount is being expended zo produce a smaller 
amount of cutpun (Q1) than it is possible of producing. 
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Addit icr.ally. Figure 2.5 shows that, if other factors of 
production are hsld constant, it is not possible zo produce 
more than Q2 (for example Q3) with a limit of M dollars 
available for programmer and systems analyst labor. 
Therefore, from Figure 2.5 it is demonstrated that the 
optimum mix of systems analyst and programmer labor is 
represented by the quantities Qsa and Qp respectively. 

There is still more information available from 
Figure 2.5 . As shown above, the slope of the isocost curve 
is equal to -he ratio of the prices of the inputs {-?p/Psa}, 
ani the slope of the isoquant curve is equal to the marginal 
rate of technological substitution or the ratio of the 
marginal products of the inputs (-■!? p/MPsa) , The optimum 
mix has been shewn to be the point of tangency between the 
isocost curve and the isoquant curve. Therefore, at the 
cptimum, the ratio of the prices of the inputs will be equal 
to the ratio of their marginal products. The optimal combi- 
naticn of programmer and systems analyst labor, therefore, 
is where: 



Pp/Psa = MPp/^lPsa 



(eqn 2.3) 



or alternately where: 



MPsa/Psa = MPp/?p 



(eqn 2.4) 



This second equation reveals that the optimum 
mix exists where the marginal productivity of a dollar's 
worth of systems analyst labor is equal to a dollar's worth 
of programmer labor. 
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and car. b= 



This conclusion makes intuitive sense 
generalized for any number of inputs [Hef. 5: p. 175]. What 
the relationship says is that if, at any point, output can 
be increased by taking a dollar from input X and applying 
that dollar to input Y, then it is beneficial to do so. The 
equilibrium point will necessarily be where the ratio of the 
marginal prcductiviry to cost for all inpurs is equal. 

2 • ^h§. Labor Quantity Deci sion 

The second problem is to decii? the optimal quantity 
of an input to utilize in the software development process. 
Programmer labor will be used as a representative input. 

It was shown above that the marginal productivity of 
programmer labor in the production of software, holding 
other factors constant, is positive over the relevant range. 
In other words, an incremental increase in programmer labor 
will result, up to a point, in an incremental increase in 
the amount of software produced. The amount of the increase 
in procrammer labor required to produce the incremental 
increase in software produced is called the marginal input 
requirement of programmer labor in the production of soft- 
ware (HIr.p) . If the market price of programmer labor is ?p, 
then, in order to achieve a marginal increase in software 
production, a marginal cost (HC) equal to the price of 
programmer labor multiplied by the marginal input require- 
ment of programmer labor in the production of software will 
be incurred. The equation is: 

MC = ?p*HIHp (sgn 2.5) 

or alternately, since it can be shown that the marginal 
input requirement is equal to the inverse of the marginal 
pro duct: 
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MC 



P p*1/MPp 



(eqn 2.6) 



The marginal revenue (MR) received by selling the 
incremental amount of software produced can also be calcu- 
lated. If the market price of the software produced is Rs, 
then The marginal revenue is equal to this market price 
mulriplied by the increase in scfrware produced as a result 
of an incremental increase in proarammer labor. This second 
term is rhe marginal product of programmer labor in the 
production of software. The marginal revenue equation is: 

:iE = Rs^IiPp (eqn 2.7) 



Because 

occur at differ 
discount them to 

Pres ent 

Present 



the flow of fu 
ent periods in 
present values 

Value of MC = 

Value of MS = 



nds for costs 
time, i* is 
before ccmparin 

-rt 

?p*MI?.p*e 



-rt 

Rs*MPp*e 



and revenues 
necessary to 
CT ^ b 21 ! 



(eqn 2.8) 



(eqn 2.9) 



The difference between the present value of the 
marginal revenue and the present value of the marginal cost 
is the net present value of a marginal increase in the 
amount of programmer labor used. If this net present value 
is positive, that is if the present value of marginal 
revenue is greater than the present value of marginal cost, 
then it is profitable to increase the amount of programmer 
labor used. If the net present value is negative, then it 
is profitable to decrease the amount of programmer labor 
used. 
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At the opiimua, all o-her factors remaining 
constant, programmer labor (or any other input) should be 
acquired to the point where the present value of marginal 
revenue equals the present value of marginal cost. In 
symbols this is where: 

-rt -ct 

Pp*MIBp*e = Rs*MP?*e (eqn 2.10) 



A prcble I i 
framework is the 
production function 
especially in view 
subject. A majcr b 
work is ins compatib 
shown by Sin- Dor and 
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for rhe software development process, 
of nhe paucity of good databases on the 
enefit of this type of conceptual frame- 
ility with linear programming methods as 
Jones [ Ref . 6 ]. 
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HI. SIZE DF THE WORK GROUP 



A. INTRODOCTIOH 

The complex nature of software development projects has 
necessitated the decomposition of the overall task into a 
multitude of lesser tasks and the assignment of groups of 
people to accomplish those tasks. Dne would think that the 
larger the group of people assigned to a task, the shorter 



would be the completion time for the task 



her erore , 



order to meet project deadlines, attempts have been made to 
speed the completion of complex software development 
projects by simply adding more manpower to the project. The 
fallacy of this belief has been widely noted, most promi- 
nently in Brocks’ widely read book The Ivthical il£tth in 
which Brooks identified some of the factors which restrained 



:Lnc re asea 


group srze 


irom resu^ 


ting in aecreasea 


prcgect 


com pie^.icn 


rime ; and 


in which 


he described how 


’’adding 


manpower ■ t 


c a late 


soft ware 


project makes it 


later . " 



[Ref. 3: p. 25] The impact of this phenomenon on the soft- 
ware production function was discussed in the previous 
chapter. This chapter will analyze how and why the size of 
the work group contributes to this phenomenon, and how the 
negative influence on productivity may be mitigated. 



B. PRODUCTIVITY IN GROUPS 

From studies as well as from our own work experience we 
know that members of a group working on a task do not spend 
all of their time doing constructive work. Some percentage 
of the time is spent on coffee breaks, meetings, illness, 
training, vacations, communicating, socializing, etc. For a 
10 member group ’’the non-productive time expected for each 
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member is 25 percent for vacation aad "he like; 10 percent 
for idle time; and a base of 10 percent for time spent 
communicating: a total of 45 percent. We may therefore 

estimate that 55 percent of each employees time can be 
considered productive in a group of up to 10 employees." 
[Bef. 4: p. 3] Fried defines productivity in a software 

development project as "developing a system with the 
following character istics: - Maintainability (documented, 

modular, etc.) - Effectiveness (meets actual user needs) 
Efficiency (uses minimal resources)." [Ref. 4: p. 8] 

The portion cf non-productive time that is most variable 
with group size is the communication time. If each member 
of the group has to interact with each other in the accom- 
plishment of the task, the number of interactions rises 
dramatically with the number of peoDle involved. If K were 
the number of people in the group, the number of interac- 
tions (N) would be given by the formula: 



N = (K-1) /2 



(eqn 3.1) 



This formula shows that the number of interactions in 
the group increases in exponential fashion with an increase 
in group size. This communications effort has proven to be 
a determining factor of productivity time in a group. Fried 
[Ref. 4] has developed the following formulae for computing 
the the percentage of productivity time: 



Pt = K*(T* . 55 - .3 001* (K* K-1 /2) ) (eqn 3.2) 



whs re : 

Pt = productivity time 

T = individual employee hours per work period 
K = the number of people in the group. 
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The productivity percentage in the work group is therefore: 



Pp = 100=>(.55 - .0001* K*(K-1)/2 ) (egn 3.3) 



whe re : 

Pp = percentage of productive time 
K = rhe number of people in tne group. 

Solving the above equarions for a 10 member group 
working a 40 hour work week: 

Pr = 10* (40=!' .55 - .000 1 (10* 10-1 /2) ) = 218.2 
Pp = 100 *(. 55 - .00 01 1 0*(10- 1)/2 ) = 54.55 



wnereas no; 



0 member arouo workin; 



e same nours: 



Pt = 80* (40* .55 - .000 1*(30* 80-1 /2) ) = 748.8 
Pp = 100*(. 55 - .00 01* 80*(30- 1)/2 ) = 23.4 



Table I demonstrates how the productivity percenrage 
varies for groups of various size. 

Fried [Ref. 4], and ;?einberg [Ref. 7] have experienced 
this inverse relationship between group size and produc- 
tivity in complex projects with which they have been 
associated. Furthermore, Fried postulates than it is 
possible to reach a point of negative marginal productivity. 
This is consistent with Brooks' [Ref. 3] earlier findings 
that, after a point, adding manpower can increase time no 
completion rather than decrease it. 
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TABLE I 

Group Size and Productivity Percentage 



up size 


Proiuctivitv p 


10 


LH 

• 

U1 ( 


20 


53. 1 


ao 


47.2 


60 


37.3 


30 


23.4 



C, SSALl PBOJECT TEAMS 

The above findings suggest that, or. the basis cf produc- 
tivity time, project teams should be created which are of 
limited size. A team with two memoers would seem to have 
the highest productivity percentage; but the additional 
coordinatio.n and communication that would be required 
between groups, as well as the limited division cf labor 
possible within the group, would eliminate any possible 
advantages. Alternately, too large a group results in low 
or negative marginal productivity. 

Brooks [Ref. 3] encountered this dilemma of balancing 
the desireable aspects of small groups against the absolute 
need to produce the large and complex OS/360 system within 
time and budget constraints. He described his problem as 
follows: 



For effiency and conceptual integrity, one prefers a few 
good minds doing design and c onstruction. Yet for large 
systems one wants a way to bring considerable manpower to 
bear, so that the product can make a timely appearance. How 
can these two needs be reconciled?” [Ref. 3: p. 31] 
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The answer that Brooks [Ref. 3], Mills [Ref. 8], and 
orhers have advocated is the chief programmer team concept. 
This concept calls for a 10 person team headed by a chief 
programmer who designs, codes, tests, and documents the 
system; and who is totally responsible for the product. All 
the other team members are tasked with supporting the chief 
programmer in his duties. The other members of the team and 
their duties are: 



- The "copilot" 


’who 


serves as the orimary 


assist an 0 ana 


understudy to 


the 


chief programmer; 




- The adrainistra 


tor 


who handles the log is 


"ics and 



administrative coordination for the team; 

- The editor who reviews che chief programmer’s rough 
documenrarion and performs the necessary editing and 
reworking required to produce the final produce; 

- Two secretaries, one each fer the administrator and the 
editor, for the necessary typing, filing, 
correspondence, etc.; 

- The program clerk who maintains the program product 
library ; 

- The ’’toolsmith" who provides basic utilities, creates 
macro libraries, and in general facilitates and ensures 
the adequacy of computer services; 

- The tester who designs and plans module and systems 
testing, produces test cases, test data, etc.; 

- The language lawyer who is expert in the chosen 
programming language and can advise the chief 
programmer on sophisticated or intricate uses of the 
language. [Ref. 3: pp. 32-35 ] 
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The hierarchy cf individuals performing specialized 
functions in support cf a group leader nor only provides the 
benefits cf division of labor and specialization discussed 
earlier, it also provides conceptual integrity in design and 
coding, as well as simplifying the interpersonal communica- 
tion required. This reduction in communication requirements 
coupled with the small size of the team results in a higher 
productivity percentage for the team. Figure 3.1 illus- 
trates the communication patterns within the chief 
programmer team. [3ef. 3; p. 35] 



1 




Figure 3.1 Co* aunication Patterns in 10-f!an Programming Teams. 



^ • S ocia l D vnam ics Considerations 

The small size of these teams and the specialization 
of function within them also helps to mitigate the negative 
impact cf such social dynamics as the ’’Commons Dilemma” 
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[Ref. 9] and "social loafing" [Ref. 10]- These dynanics 
suggest that individuals in a group may use more than their 
share of a common resource or contribute less than their 
share to the common effort if they feel that their excesses 
or delinquencies will not be distinguishable from the common 
consumption or effort. The small size of the team and the 
specialized functions of the team members in the chief 
programmer team concept alleviate these problems by making 
each team member accountable for a visible, distinct, seamen- 
of the group effort. 

2. Pssiss C cnsidera ti o ns 

In order to reap the benefits of small groups such 
as the chief programmer teams in large, complex projects it 
is necessary to have many of these teams working concur- 
rently in coordinated fashion. To minimize the coordination 
and management required, and thereby enhance the productive- 
ness of each team, it is essential that the overall system 
be designed in a structured, modular manner with clear, 
unambiguous specifications and documentation. Such stan- 
dardized 'design methodologies will be discussed later in the 
paper. Their benefit is that they allow independent, 
concurrent production of modules which can be "integrated 
into the whole without further coordination." [Ref. 4; p- 
10 ] 

D, SOHBARY 

The above analysis indicates thai, in a systems develop- 
ment project, the size of the work groups should be 
relatively small. The benefits of these small work groups 
lie mainly in the improved percentage of time spent produc- 
tively. This benefit results not only from the fewer number 
of communications within the group; but also from the 
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ability cf small, hierarchically structured groups to miti- 
gate some of the non-productive aspects of group dynamics. 
Certain managerial and syszem design techniques may be 
required to ensure that these benefits result. These tech- 
niques include: 

- Proper scheduling and task loading based on an 
understanding of productive time. 

- Clear assignment of task and oroduct responsibility, 
accompaniea by measurement and rsccgni-^ion of 
individual performance. 

- Modular desion that supports clear assianment of 
product responsibility! ■ [3ef. 4: p. 10] 
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IV. SONDARDIZ ATION OF ACTIVITIES 



A. REASONS FOR STANDARDIZATION 

Standardization of activities is a very important 
element of organizational structure because it is the way in 
which the crganizaticn ensures that its efforts will produce 
predictable results in *he quantity, quality, t ineiin-^ss, 
and cost of the software produced. An activity is standard- 
ized when the procedure is made uniform and consistent. 

The advantages of standardization of activities have 
long been recognized in production processes. In an automo- 
bile assembly line the order in which activities are 
performed, the manner in which they are performed, the qual- 
ifications of workers, the rate or production, the tools, 
parts, e-c. , are all highly standardized. This standardiza- 
tion is one of the reasons ~hat this type of production is 
so successful. There are, of course, significant differ- 
ences between automobile assembly and software development, 
but the benefits of standardization of activities are rsccg- 
nizeable in both areas. 

The goals of standardization are to produce predictable 
results in quantity, quality, timeliness, and cost. The 
quantity metric could be lines of code, number of modules, 
applications programs completed, etc., depending on manage- 
ment's desired control system. The quality metric is a 
complex and multifaceted one. Nhat constitutes good soft- 
ware is a question that continues to be debated. 
Reliability, predictability, readability, maintainability, 
modif iabilt y, flexibility, robustness, efficiency, and 
understandabilit y are some of the concepts currently associ- 
ated with evaluating the quality of software. 
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The timeliness and cost me-crics are fairly simple 
concepts. The time it rakes to complete a projecr and the 
cosr of the project will vary with rhe nature of rhe 
project, assigned resources, etc,; with the general goal 
being to complete the project within the budgeted cost and 
time period. The predictability of the above merries is 
itself a major goal of standardization. From a management 
viewpoint, the predictability of the outcome of the organi- 
zation's efforts is absolutely essential for the planning 
and cor.rrol of rhose efforrs. 



B. SOFTWARE ENGINEERING 

The field of software engineering has developed in 
response to the need to improve and srandardize the methods 
and techniques employed in the sofrware developmen* process. 
There have beer, various attempts to define the field of 
software engineering. Nasserman and Freeman [Ref, 11] 
defined it as: 



rhe attempt to seek out and use rechnigues that can 
assisr in the economical develcomenr of sofrware which 
executes reliably and efficiently on real machines, 
making effective use of the human resources available. 
Software Engineering tries to take an overall systems 
viewDoint in which the optimization of all resources - 
developmental as well as operational - is considered. 
[Ref. 1l: p. 256] 



B.W. Boehm [Ref. 12] shows a slightly different perspec- 
tive in his definition of software engineering as: 



the means bv which we attempt to produce all of this 
software in a way that is both cost- ef f ective and reli- 
able enough to deserve our trust... (It is) the 
oractical application of scientific knowledge in the 
design and construction of computer programs and the 
associated documentation reguirea to develop, operate, 
and maintain them, [Ref. 12; p. 1227] 
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The decision of which techniques and methodologies to 
utilize in the software development process is a choice of 
the technology to employ. This choice is of critical impor- 
tance to the development process because the technology 
employed serves to define the sof-cwars production function. 
"The production function summarizes the characteristics of 
the existing rechnolcgy ao a given point in time; it shows 
the technological constraints that the firm must reckon 
with." [Ref, 5: p. 146] Therefore, by selecting certain 

techniques and m erhodclogie s, and implementing nhem as stan- 
dards for the conduct of the development process, the choice 
of the technology which will form the boundary of the organ- 
ization's productivity is made. The importance of 

structured, modular software design to -^he implementation 
and effectiveness of small project teams was discussed 
earlier in this paoer. To provide continuity, design meth- 
odologies will be used as the example of how activities in 
the development process are being standardized to contribute 
to the success of software development projects. 

C. THE DESIGN PHASE 

The importance of standardizing the design phase of a 
software development project has grown with that of the 
design phase itself. Developing standard design methods is 
one or the thrusts of software engineering and many 
approaches have been championed. The standard approaches 
that have been most widely accepted are those which advocate 
a structured approach to the design process. The very term 
"structured" implies that seme sort of standard me~hcd, 
mechanism, or approach is used. Stevens, Myers, and 
Constantine [Ref. 13] have defined structured design as "a 
set of proposed general program design considerations and 
techniques for making coding, debugging, and modification 
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easier, faster, and less expensive by reducing complexity." 
[Ref. 13: p. 216] 

1 • I co^Down De sign 

Perhaps the besr known strurtured design technique 
is Top-down design which results from a stepwise refinement 
process. Stepwise refinement is a methodology which 
consists of the following steps: 

1) Start with a high-level, overall snarement or 

description of the d<=sired system fu?.c~ion made up 
of: a) the overall soatement of ohe system function; 

and b) comments/description of the next level of 
deta il. 

2) Refine the abcve by replacing the comment s/description 
with a) lower level functions; and 

b) comment s/d escription of the next level. 

3) Repeat the refinement until there are no comments left 
so that the bottom level consists only of functions 
which can be implemented on the ha rd war^/sof tware 
machine. 

This Top-down design can be represented as a hier- 
archy of modules in which the "uses" relationship exists 
between the higher and lower level modules. The "uses" 
relationship can be interpreted as "requires the presence of 
a correct version of." [Ref. 14: p 230] 

Brooks [Ref. 3] termed Top-down design "the most 
important new programming formulation of the (1970-1980) 
decade." [Ref. 3: p. 144] Among the benefits that Brooks 

attributed *o Top-down design were four ways in which it 
assists the designer to avoid errors or bugs: 

First, the clarity of structure and representation makes 
the precise statement of requirements and functions of 
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the modules “iasier. Second, the partition inq 
independence of modules avoids system bugs. Third, 
suppression of detail makes flaws in the structure m 
apparent. Fourth, the design can be tested at each 
irs refinement steps, so tesring can start earlier 
focus on the proper level of detail at each ste 
[ Ref. 3: p. 14 3^ 



P 



It 



The concepts of modularity and clear structure 
present in the Top-down design approach are represented in 
the more resent design approaches although the manner and 
criteria of the decomposition have varied in some cases. 



2 . Q.il^Z-3^ 

Parnas [Ref. 15] has proposed a design merhodclogy 
which focuses on designing software that can be easily 
changed. His approach uses a modular decomposition based 
upon information -hiding modules within a hierarchical struc- 
ture. Parnas £Ref. 15] proposes a design procedure which 
would include: 



1) Identifying all difficult design decisions and these 
design decisions which are lik-ly to chance. 

2) Isolating the changeable design decisions into 
information-hiding modules with clearly defined 
interfaces which will be unaffected by potential 
changes. 



3) 

4) 



Establish the "uses” relationship be 

Set up the "uses" hierarchy by: a) 

at level 0 (i.e. those modules which 
module) ; and h) working up the hiera 
level (i.e. that module which is use 
module) . 



w ween 


th 


e modules. 


listing 


the modules 


use 


no 


other 


rch y 


to 


the top 


d by 


no 


other 
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Parnas' approach to sysrsm design has beer, of 
significant interest to chose in the software engineering 
field because his methods; 

1) Bring software design closer to being a science. 

2) Result in programs which are easier to fix and modify. 

3) Result in programs which are easily subsettable and 
extendable. 

4) Allow modules ro be programmed ani cesned 
independently [Ref. 15]. 

Nore than the ability to iniependently procram and 
test modules which is cited here and in suseguent design 
techniques is what was shown to be neccessary for the effec- 
tive utilization of small project teams within a large, 
complex project. 

3, ^fsi^Ii Simole 3onnecticns and 

Stevens, Myers, and Constantine [Ref. 13] have 
proposed structured design techniques based or. principles 
similar to those of Parnas. These •techniques emphasize a 
structure of simply connected, functionally bound modules. 
They emphasize the use of structure charts rather than flow- 
charts in the design phase. Reference 13 provides the 
somewhat lengthy step-by-step procedure for developing the 
input-process-output general structure that Stevens, Myers, 
and Constan-^ine advocate. 

The benefits of this design technique include: 

1) Its ccmpatability with the HIPO hierarchy charting 
format [Ref. 16]. 

2) Better maintainability of resultant programs. 

3) Results in independently programmable and testable 
modules. 



35 



4) Ability to identify and oprimize critical modules. 

5) Ability to develop rauseable modules. 

^ • Des igni S^STems as Mo dels 

Jackson [Ref. 17] has proposed a different approach 
to software design. He argues rhat there are some serious 
disadvantages to the functional approach to systems design. 
Among the disadvantages he cires are: 

1) The difficulty of applying functional design to complex 
problems. 

2) The frequent, requests for changes in system function. 

3) The lack of a clear distiction between functions to be 
performed by software and those to be performed by 
hardware . 

Jackson's approach is to design the system primarily 
as a model of the reality which it is representing ani 
subsequer.'ly superimpose the desired functions on the model. 
The steps’ in the process are: 

1) Represent each active entity in the real world system to 
be modeled as a process acting on a dedicated processor. 

2) Represent the communication between the processes 
themselves, and between the processes and the outside 
world as a data stream. 



3) Superimpose desired functions on the model. 
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Kenard [ Bef . 18] of the Cominunications and Computer 
Science Department of Exxon corporation has used Jackson’s 
design method in ccmbination winh top-down implementation 
and structured walkthroughs. This combination was called 
the Program Structure Technology (PSI) . Menard found that 

the benefits derived from the use of PST, measured 
statistically for several applications, include 
increased programmer productivity" and reduced mainte- 
nance costs. with PST as a design method, the 
programmer can produce double the industry standard 
number of lines or code oer year. The reduced mainte- 
nance cost? result from encounterinc -^ewer buas in "^he 
program code and from having the simpler, structured 
code which is easier to modify." ^Ref. 18; p. 89] 

Menard [Bef. 18] found that, whereas the PST method 
required them to spend more time on the design phase of a 
project, this time was more than made up in the implementa- 
tion phase of the project. 

D. SDMMAHY 

The design methodologies discusssed above are import^.n- 
fcr providing conceptually sound frameworks for the design 
of "good" software; but, in order to r=“alizs the maximum 
benefit, the chosen methodology must be standardized 

throughout the development project. It is the standardiza- 

tion of the process which provides the organization with the 
benefits by reducing the necessity for communication and 
coordination while maintaining design integrity and facili- 
tating successful integration. 

The standards themselves form the basis of the organiza- 
tion's planning, control, and evaluation processes. Biggs, 
Birks, and Atkins [Ref. 19] summarized the importance of 
standardization as follows; 

The standard atproach to phases, steos, activities, and 
tasks makes it ‘possible to plan, control, and evaluate 
progress during the systems development process without 
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inhibiting ~he nacessary analynicil and creative work 
required ro produce successful' new sysnems. The struc- 
ture allows atanagement to make and monitor incremental 
commitments and the ability to impact interim results. 
It is an important key to an organization’s effective 
management of the systems uevelooment process. 
[Ref, 19: p. 47] 



The importance of standardizing the activities in the 
software development process continues to receive management 
attention. The emphasis on developing standard methods and 
approaches to requirements analysis, specifications, docu- 
mentation, integration, and testing manifests the vital 
importance of activity standardization in the software 
development process. 
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7. SOMMMT AND CONCLOSIONS 



Organizational structure has long been recognized as 
having an important impact on an organization's ability to 
accomplish its objectives. ilanagsre, therefore, need to be 
aware of how organizational structure affects performance. 
This paper has provided the managers of software development 
projects with an analysis of rn= imporrance of several 
elements of organizaticnai snr ucrure , an i cf how they can 

use this knowledge no make decisions aboun organizaticnai 
structure which will have a positive impact on the success 
of their projects. 

The first structural element analyzed was "he speciali- 
zation of activities. It was found that the manager coul’ 
proceed with specific or general knowledge of the software 
production function as provided by Brooks [Ref. 3], rrned 
[Ref. U], Weinberg [Ref. 7], and Zin-Dcr and Jones [Ref. 6], 
to develop conceptual frameworks to assist in making deci- 
sions for optimizing the utilization of the specialized 
inputs into the software development process. Twc of the 
most important decisions are the determination of the 
optimal mix of these inputs, and the determination of the 
optimal quantity of a particular input to aquire. 

The optimal mix cf the various inputs was shown to exist 
at that point where the marginal productivity of a dollar's 
worth of any input in the production of the software output 
is equal to the marginal productivity of a dollar's worth of 
any other input. 

The optimal quantity cf an input to employ, other 
factors remaining constant, is that quantity at which the 
present value of the marginal revenue received due tc a 
marginal increment of the input is equal to the present 
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value of the marginal cost incurrad do to that marginal 
increment. 

This type of conceptual framework provides the addi- 
tional benefit of being compatible wirh technical analysis 
and linear programming as shown by Ein-Dor and Jones 

[Ref. 6]. 

One element of organizational srructure that affects 
labor productivity and thus rhe production function is the 
size of the work group. Brooks [Ref. 3] found that, after a 
point, increases in programmer labor contribured less and 
less to software production and than, ulrimately, increases 
in programmer labor would have a negative impacr on produc- 
tion. Fried [Ref. 4] experienced similar results as did 
Weinberg [Ref. 7]. Fried [Ref. 4] and Brocks [Ref. 3] found 
that communications requirements were the major factor in 
reduced productivity as group size increased. Fried 
[Ref. 4] has developed a formula from case studies and prac- 
tical experience which can be used to calculate the amount 
of time spent spent productively by a group based upon the 
size of the croup. This formula and Weinberg's [Ref- 7] 
findings suggest that groups with more than 3D people will 
spend less than 50 percent of their time doing productive 
wor k . 

Cass and Edney [Ref. 9] and Latane, williams, and 
Harkins [Ref. 10] discovered aspects of social dynamics 
which also contribute to reduced individual productivity in 
large groups. These findings indicate that individuals tend 
to use more resources and contribute less effort if their 
consumption and performance are felt to be indist inqishable 
from that of the group. 

A possible solution to the team size problem in view of 
these findings is the chief programmer team concept. This 
hierarchically structured, 10 person team is organized in a 
manner which provides for design integrity, quality output. 
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simple ccramun ica tion partarns, visible job performance, and 
high producrivit y. Successful implementation of rhis small 
team concept in complex projects requires a modular project 
design as well as managerial emphasis on planning, control, 
and evaluation. 

The achievement of good planning, control, and evalua- 
tion requires the standardization of software development 
activities including: requirements analysis, specifica- 

tions, design, documentation, integration, and tasting. The 
selection and implementation of standard techniques and 
methodologies represents the choice of technology for the 



project. This technologi ca 1 choice, in turn, serves to 
define the production function for the project. 

Stevens, Myers, and Constantine [Ref. 13], Parnas 
[Ref. 15], and Jackson [Ref. 17], among others have proposed 
software design methodologies which have been used with 
success as the standard for software projects. The modular 

fined interfaces resulting from the 

success ful 



structure and clearly 
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tance of activity standardization in all phases of the 
development process as a key element of organizational 
structure. Its importance is recognized not only because it 
makes effective planning, control, and evaluation possible; 
but also for the reduction in communication and coordination 
it allows. 

The field of organizational structure and its impact on 
organizations' success is vast, with myriad subtle interre- 
lationships. It is an interdisciplinary field with 
applications from economics, operations research, 
psychology, sociology, and various technologies. This paper 
has delved into several of the relationships between 
elements of or aanizationa 1 structure and the software 
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development process. A common thread 
each element is the software develop 
tion. As the database of development 
too will our ability to analyze and 
development process. 



that has appeared in 
ment production func- 
projects improves, so 
improve the software 
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